Add support for session resumption when using client certificates#447
Add support for session resumption when using client certificates#447eh-steve wants to merge 2 commits intopion:masterfrom
Conversation
|
This is going to need some tests. |
eh-steve
force-pushed
the
session-store-support-cert-verification-expiry
branch
2 times, most recently
from
2bbb298 to
2561eb0
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #447 +/- ##
==========================================
+ Coverage 75.81% 75.87% +0.05%
==========================================
Files 96 96
Lines 5586 5599 +13
==========================================
+ Hits 4235 4248 +13
Misses 1019 1019
Partials 332 332
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I can’t really tell from the logs whether the CI is failing due to my changes… if it’s just the commit message linting, I was going to squash everything |
|
Yeah, it's just the commit message. All the other checks passed. |
Allow mutual authentication (RequireAndVerifyClientCert/ VerifyClientCertIfGiven)to work with session resumption by recording the certificate expiry time in the session struct
eh-steve
force-pushed
the
session-store-support-cert-verification-expiry
branch
from
2561eb0 to
61c44b8
Compare
|
We are looking forward for this to enable IoT devices with client certificates to resume their sessions. That would save traffic and increase battery life. We have over 100k devices in field and pushing to use DTLS as much as possible. |
|
What's your take on this @theodorsm @adrianosela? It feels super valuable to not waste as much resources/save battery life. I don't want to risk security though. I can rebase/fix up if that helps. |
|
@Sean-Der I think this is worthwhile having. But we should make |
|
@niondir, would "session resumption and pre-shared-key (PSK)" as described in the (D)TLS 1.3 specification (RFC 8446 section 2.2) solve your usecase? I think this is a safer way of doing resumption. We have just recently implemented all necessary extensions, but the handshake is yet to be implemented and will take some time. DTLS 1.3 also has the 0-RTT session resumption with early data that would save a round trip (and energy for IoT usecases). @Sean-Der, @adrianosela I would be against having an unsafe session resumption mechanism in place (even if it's disabled by default) if DTLS 1.3 session resumption solves the issue. |
100% agree. Good call. |
We will check this. |
6 participants
Description
Previously, if a client submitted a certificate, any session resumption would be ignored in order to mitigate indefinite extension attacks as per https://curl.se/docs/CVE-2016-5419.html, but this prevented improving performance under mutual authentication use cases.
Now if
RequireAndVerifyClientCert/VerifyClientCertIfGivenare used, the certificate expiry time is recorded in the session struct, allowing the user provided session store to decide what to do with "expired" sessions.Revocations are still not handled via this mechanism, and the old behaviour can be preserved using the new config
PeerCertDisablesSessionResumption